The automation industry has had major developments in the implementation of SCADA monitoring and control systems. A need has long existed for an integrated system, which uses small PC's to run factory lines, and other large manufacturing facilities.
The integration problems were rampant in the industry. Either, hosts were inadequate or defective. A unique enterprise server was developed to facilitate the integration of software.    1. A need has long exists for a less expensive RTU.    2. A new board has been desired to reduce the costs of RTU by at least 25%.    3. A need has existed for a system, which works faster than traditional host systems.    4. A need has existed for an improved SCADA system and method of communication, which can talk to more systems as host more than traditional systems.
A vital part of any process control system is the initial communication and periodic point-to-point communication of the system, including the process input values, the database, the displays and the like. Such a communication procedure is associated with a SCADA system, which in its most generic definition is essentially a process control system. The components of a typical SCADA system comprise a SCADA device and one or more remotely connected Intelligent Electronic Devices. As used herein, the term SCADA device is used as a convenient shorthand for what may be a collection of electronic equipment, including a computer based controller, which can be a server, also termed the “enterprise server” that is used to remotely monitor communication and/or control the operation of one or more remote RTU's such as relays, meters, transducers and the like. In general, the enterprise server is located miles away from the RTUs presenting many SCADA system communication difficulties. However, such a definition should not preclude an enterprise server being located much closer, even in the same plant as the RTU or RTUs.
Communication for a SCADA system traditionally has been very time and labor intensive. The initial set up of the RTU required an expensive technician to go into the field to configure the RTU. Subsequent maintenance communication has also been particularly time and labor intensive where the RTU is in an extremely remote location, such as on a mountain top or under snow on a pipeline in Alaska with respect to the enterprise server. In such a case, transportation and communication problems have been abundant. Therefore, reducing the time and effort required to run communication of a SCADA system while insuring that the SCADA device database and overall SCADA system operation meets the highest possible accuracy standards would provide substantial cost advantages over current communication procedures.
Traditionally, RTU configuration has involved steps of:    1. Assembling and transporting to the RTU location a collection of complex and expensive test equipment and signal generators that are required to produce the needed configuration.    2. Requiring an expensive technician at the remote location to inject the data into the RTU's inputs.    3. Requiring a second expensive technician at the central location(s) to verify the RTU is correctly processing according to the new configuration.    4. Such a system presents many drawbacks. For example, two technicians at disparate locations are required to perform the service. One of the technicians may be required to travel long distances. Moreover, in most SCADA systems, the RTU must be disconnected from the process that it is monitoring and/or controlling, which may affect the process under control.    5. There is a need for method and apparatus that address the shortcomings of present communication of a SCADA system. These needs are now met by the present invention.